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Status of This Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This memo presents a techniques for efficiently implementing the 
Internet Checksum in hardware. It includes PLD code for programming a 
single, low cost part to perform checksumming at 1.26 Gbps. 


Introduction 


The Internet Checksum is used in various Internet protocols to check 
for data corruption in headers (e.g., IP) [4] and packet bodies (e.g, 
UDP, TCP) [5][6]. Efficient software implementation of this checksum 
has been addressed in previous RFCs [1][2] [3] [7]. 


Efficient software implementations of the Internet Checksum algorithm 
are often embedded in data copying operations ([1], Section 2). This 
copy operation is increasingly being performed by dedicated direct 
memory access (DMA) hardware. As a result, DMA hardware designs are 
beginning to incorporate dedicated hardware to compute the Internet 
Checksum during the data transfer. 


This note presents the architecture of an efficient, pipelined 
Internet Checksum mechanism, suitable for inclusion in DMA hardware 
[8]. This design can be implemented in a relatively inexpensive 
programmable logic device (PLD) (1995 cost of $40), and is capable of 
supporting 1.26 Gbps transfer rates, at 26 ns per 32-bit word. 
Appendix A provides the pseudocode for such a device. This design has 
been implemented in the PC-ATOMIC host interface hardware [8]. We 
believe this design is of general use to the Internet community. 
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The remainder of this document is organized as follows: 


Review of the Internet Checksum 


One’s Complement vs. Two’s Complement Addition 
Interfaces 


Summary 
Appendix A - PLD source code 
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A Review of the Internet Checksum 


The Internet Checksum is used for detecting corruption in a block of 
data [1]. It is initialized to zero, and computed as the complement 
of the ones-complement sum of the data, taken in 16-bit units. A 
subsequent checksum of the data and checksum together should generate 
a zero checksum if no errors are detected. 


The checksum allows [1]: 


- byte order "independence" 
reordered output is equivalent to reordered input 
16-bit word-order independence 
reordering 16-bit words preserves the output 
-— incremental computation 
deferred carries 
—- parallel summation 
a result of deferred carries, incremental 
computation, and 16-bit word order independence 


This note describes an implementation that computes two partial 
checksums in parallel, over the odd and even 16-bit half-words of 
32-bit data. The result is a pair of partial checksums (odd and 
even), which can be combined, and the result inverted to generate the 
true Internet Checksum. This technique is related to the long-word 
parallel summation used in efficient software implementations [1]. 


$oSa Sa Se SSeS Sao + sama stan aa aa atom acer aan + 
| high half-word | | low half-word | 
| ones-complement | | ones-complement | 
| partial checksum | | partial checksum | 
tars + a rant wraith a + 
\ / 

| (ones-—complement sum) 

toast + 

| partial checksum | 

tans + 


| final | 
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One’s Complement vs. Two’s Complement Addition 


The Internet Checksum is composed of a ones-complement lookahead 
adder and a bit-wise inverter. A ones-complement adder can be built 
either using twos-complement components, or natively. 


A twos-complement implementation of a ones-complement adder requires 

either two twos-complement adders, or two cycles per add. The sum is 

performed, then the high-bit carry-out is propagated to the carry-in, 
and a second sum is performed. (ones-complement addition is {+1ls} and 
twos-complement is {+2s}) 


a {+1s} == (a {+2s} b) + carry(a {+2s} b) 
Sodas 
halfwordl16 a,b; 
word32 c; 
a {+ls} b == 
such that: 
c=a {+2s} b; # sum value 
r = (c & OxFFFF) {+2s} (c >> 16); # sum carry 


Bits of a twos-complement lookahead adder are progressively more 
complex in carry lookahead. (OR the contents of each row, where terms 
are AND’d or XOR’d {^}) 


4-bit carry-lookahead 2’s complement adder: 
a,b : input data 


p : carry propagate, where pi = ai*bi = (ai) (bi) 
g : carry generate, where gi = ai + bi 

OutO := a0 ^ bO ^ ci 

Outl := al * bl ^- {cipo + g0) 

Out2 := a2 ^ b2 ^ (cipO0pl + g0p1 + gl) 

Out3 := a3 ^ b3 ^ (cipOplp2 + gOplp2 + glp2 + g2) 

Cout := cipOplp2p3 + gOplp2p3 + glp2p3 + g2p3 + g3 


The true ones-complement lookahead adder recognizes that the carry- 
wrap of the twos-complement addition is equivalent to a toroidal 
carry-lookahead. Bits of a ones-complement lookahead adder are all 
the same complexity, that of the high-bit of a twos-complement 
lookahead adder. Thus the ones-complement sum (and thus the Internet 
Checksum) is bit-position independent. We replace ‘ci’ with the ‘co’ 
expression and reduce. (OR terms in each row pair). 
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4-bit carry-lookahead 1’s complement ring adder: 


OutO = a0 ^ bO ^ (g3 + g2p3 + glp2p3 + g0plp2p3) 
Out1 = al ^ bl ^ (g3p0 + g2p3p0 + glp2p3p0 + g0) 

Out2 = a2 ^ b2 ^ (g3p0p1 + g2p3p0p1 + gl + g0p1) 
Out3 = a3 ^ b3 ^ (g3p0plp2 + g2 + glp2 + gOplp2) 


A hardware implementation can use this toroidal design directly, 
together with conventional twos-complement fast-adder internal 
components, to perform a pipelined ones-complement adder [8]. 


A VLSI implementation could use any full-lookahead adder, adapted to 
be toroidal and bit-equivalent, as above. In our PLD implementation, 
we implement the adders via 2- and 3-bit full-lookahead sub- 
components. The adder components are chained in a ring via carry bit 
registers. This relies on delayed carry-propagation to implement a 
carry pipeline between the fast-adder stages. 


Full-lookahead adders in a toroidal pipeline 


+-+-+-+  +-+-+-+  +-+-+  +-+-+-+ +-+-+-+  +-+-+ 
lilili] fifili Jalap  fäflilil Jijiji aa 
lF/E|D]  felsla]  fəfs| {7lels|  faf3ļ2| [zio] 
+-+-+-+  +-+-+-+ +-+-+  +-+-+-+ +-ł-+-+  +-+-+ 

"4n "4n" Nn wan "4n nyn 
+-+-+-+  +-+-+-+  +-+-+  +-+-+-+ +-+-+-+  +-+-+ 
ls{s{s| [s|s|s| fsļs| Jsļsls| fsļsļs| Js[s] 
IFlE[D] |cljBlal foils;  [7leis|  lalal2|  {ziol 
+-+-+-+  +-+-+-+  +-+-+  +-+-+-+  +-+-+-+  +-+-+ 
vV | vV | vV | vV | vV | vV | io 

+-+ +-+ +-+ +-+ +-+ +-+ 

| [c] [c| [c| [c| [c| lc] | 
| [5] | 4| [3] |2| [1] Jol | 
| +-+ +-+ +-+ +-+ +-+ +-+ | 
+---------------------------------------------------------- + 


Implementation of fast-adders in PLD hardware is currently limited to 
3-bits, because an i-bit adder requires 4+2^i product terms, and 
current PLDs support only 16 product terms. The resulting device 
takes at most 5 "idle" clock periods for the carries to propagate 
through the accumulation pipeline. 
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Interfaces 


The above device has been installed in a VL-Bus PC host interface 
card [8]. It has a hardware and software interface, defined as 
follows. 


Hardware Interface 


The Internet Checksum hardware appears as a single-port 32-bit 
register, with clock and control signals [8]: 


CLR---> | | 
OE---->| 32-bit register as | 
CLK--->| 2 adjacent 16-bit | 
ICLK-->| ones-complement sums 


<---/---> 32-bit data bus 


ADD---> 

4+---------------------- + 
CLR = zero the register 
OE = write the register onto the data bus 
CLK = clock to cycle the pipeline operation 
ICLK = input data latch clock 
ADD = initiating an add of latched input data 


CLR causes the contents of the checksum register and input latch to 
be zeroed. There is no explicit load; a CLR followed by a write of 
the load value to a dummy location is equivalent. 


The OE causes the register to be written to the data bus, or tri- 
stated. 


The CLK causes the pipeline to operate. If no new input data is 
latched to be added (via ICLK, ADD), a virtual "zero" is summed into 
the register, to permit the pipeline to empty. 


The ICLK (transparently) latches the value on the data bus to be 
latched internally, to be summed into the accumulator on the next ADD 
signal. The ADD signal causes the latched input data (ICLK) to be 
accumulated into the checksum pipeline. ADD and ICLK are commonly 
tied together. One 32-bit data value can be latched and accumulated 
into the pipeline adder every 26-ns clock, assuming data is stable 
when the ADD/ICLK signal occurs. 


The internal 32-bit register is organized as two 16-bit ones- 
complement sums, over the even and odd 16-bit words of the data 
stream. To compute the Internet Checksum from this quantity, ones- 
complement add the halves together, and invert the result. 
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Software Interface 


The device is used as a memory-mapped register. The register is read 
by performing a read on its equivalent memory location. 


The device is controlled via an external memory-mapped register. Bits 
in this control register clear the device (set/clear the CLR line), 
and enable and disable the device (set/clear the ADD line). The CLR 
line can alternatively be mapped to a memory write, e.g., such that 
reading the location is a non-destructive read of the checksum 
register, and a write of any value clears the checksum register. The 
enable/disable control must be stored in an external register. 


The device is designed to operate in background during memory 
transfers (either DMA or programmed I/O). Once enabled, all transfers 
across that bus are summed into the checksum register. The checksum 
is available 5 clocks after the last enabled data accumulation. This 
delay is often hidden by memory access mechanisms and bus 
arbitration. If required, "stall" instructions can be executed for 
the appropriate delay. 


For the following example, we assume that the device is located at 
CKSUMLOC. We assume that reading that location reads the checksum 
register, and writing any value to that location clears the register. 
The control register is located at CTLLOC, and the checksum 
enable/disable bit is CKSUMBIT, where 1 is enabled, and 0 is 
disabled. To perform a checksum, a programmer would clear the 
register, (optionally initialize the checksum), initiate a series of 
transfers, and use the result: 


[KKKKKKK initialization aK KK KKK / 


*(CTLLOC) &= ~((ctlsize) (CKSUMBIT) ); /* disable sum */ 
(word32) (* (CKSUMLOC)) = 0; /* clear reg * / 
*(CTLLOC) |= CKSUMBIT; /* enable sum */ 


{ (optional) write initial value to a dummy location } 


/***** perform a transfer *****/ 
{ do one or more DMA or PIO transfers - read or write } 


/***** gather the results *****/ 


*(CTLLOC) &= ~((ctlsize) (CKSUMBIT) ); /* disable sum */ 
sum = (word32) (* (CKSUMLOC) ); /* read sum * / 
sum = (sum & OxFFFF) + (sum >> 16); /* fold halves */ 
sum = (sum & OxFFFF) + (sum >> 16); /* add in carry */ 
ipcksum = (halfword16) (~(sum & OxFFFF)); /* 1’s negative */ 
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Summary 


This note describes the design of a hardware Internet Checksum that 
can be implemented in an inexpensive PLD, achieving 1.26 Gbps. This 
design has been implemented in the PC-ATOMIC host interface hardware 
[8]. We believe this design is of general use to the Internet 
community. 


Security Considerations 


Security considerations are not addressed here. The Internet Checksum 
is not intended as a security measure. 
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Appendix A: PLD source code 


The following is the PLD source code for an AMD MACH-435 PLD. The 
MACH-435 is composed of 8 22V10-equivalent PLD blocks, connected by a 
configurable internal matrix. 


---- (PLD source code follows) ---- 


TITLE PC-ATOMIC IP Sum Accelerator - 1-clock 2- and 3-bit 26 ns version 
PATTERN ip_sum 

REVISION 1.01 

AUTHOR J. Touch & B. Parham 

COMPANY USC/ISI 

DATE 06/21/94 


CHIP ip_sum MACH435 

; accumulates in 1 clock (1 level of logic) 

; resources allocated to reduce fitting time 

; uses an input register "dl" to latch the data bus values on rising edge 
; accumulates a hi/lo ones-complement sum in register "q" 

; the input and output are accessed via bidirectional pins "dq" 

; uses 2 groups of 6 carry bit registers "cy" 

; use 3-bit full-adders with carry lookahead (settles in 6 clocks) 
; group 16 bits as [000102 030405 0607 080910 111213 1415] 

$ [161718 192021 2223 242526 272829 3031] 

; locking the pins down speeds up fitting and is designed to force 


; 4-bit components into single "segments" of the PLD. 
; we could have indicated the same thing via: 


H GROUP MACH_SEG_A dq[6..0] 

H GROUP MACH_SEG_B dq[14..8] 
; GROUP MACH_SEG_C dq[22..16] 
; GROUP MACH_SEG_D dq[30..24] 


7 
; control pins: 


, 
PIN 20 clk ; adder clock 


PIN 62 ip_add ; add current data to sum 

PIN 83 ip_sum_ena ; output current sum 

PIN 41 ip-elr ; clear current sum 

PIN 23 ip_dclk ; input data latch (tied to clk, or not) 
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i 
; dq are data bus pins 
; dl is the input register 


PIN [Or Bd dq[6..0] IPAIR dl1[6..0] ; IO port 
PIN [18..12] dq[14..8] IPAIR d1[14..8] ; IO port 
PIN [30..24] dq[22..16] IPAIR d1[22..16] ; IO port 
PIN [39.5333] dgq[30..24] IPAIR d1[30..24] ; IO port 
PIN ? dq[31,23,15,7] IPAIR d1[31,23,15,7] ; IO port 


; q is the partial checksum register 
; dl is the input register 
; dq are the data bus pins 


NODE ? q[31..0] OPAIR dq[31..0] ; internal data in reg 
NODE ? d1[31..0] REG ; input reg 
; cy are the carry register bits 


NODE ? cy[31,29,26,23,21,18,15,13,10,7,5,2] REG 
;l-bit internal carry bits 


EQUATIONS 


r 
; trst is the tri-state control, 0 means these are always inputs 


ip_add.trst = 


0 
ip_clr.trst = 0 
ip_sum_ena.trst = 0 


i 
; grab data to the input register on every clock (irrelevant if invalid) 


d 

aries 0J eLkt = ip_dclk ; grab data all the time 
; don’t use setf, rstf, or trst for dl 
; we want dl to map to input registers, not internal cells 
; besides, input registers don’t need setf, rstf, or trst 


i 
; control of the checksum register 


dq[31..0].clkf = clk ; clk clocks everything 
dq[31..0].setf = gnd ; never preset registers 
dq[31..0].rstf = ip_clr ; clear on reset 

dq[31..0].trst = ip_sum_ena ; ena outputs sum - read 
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control for the carry register 


cy (131,29, 26,23, 21,18;19,13,10;, 77 39;2] -CIK 
cy[31,29,26,23,21,18,15,13,10,7,5,2].setf 
ey [31,29,26,23; 21, 18)19,13,10) 7,572) .rstt 


£ 
d 


r 


INPUT DATA LATCH 


in 


Hardware 


clk 
gnd ; 
ip cele 5 


April 1996 


never preset 
clear on reset 


nothing fancy here - grab all inputs when ip_add signal is high 


aiey 


d1[31..0] 


COMBINATORIAL ADDER 


built as a series of 
with carries sent to 


sum[n] are sum bits 
cy[m] are carry bits 
"3:+:" is XOR 

SUM[0O] = (AO :+: BO 
CY[0] = ((AO * BO) + 
actually, the latter 
CY[0] = ((AO * BO) + 


because the XOR won’t be invalidated by the AND case, 


grab data in input register 


:= dq[31..0] 


2-bit and 3-bit 


(carry-lookahead) 


the carry register "pipeline" 


2+: CARRY_IN) 


( (AO :+: BO) 
can be rewritten as 


((AO + BO) 


* CARRY_IN) ) 


* CARRY_IN) ) 


result is always 1 from the first term then anyway 


this helps reduce the number of XOR terms required, 


a limited resource in PLDs 
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; SUM THE LOW-ORDER WORD 


1 


; the first 5 bits [0..4] of the low-order word 


q[0] = (q[0] :+: (ip_add * dl[0]) :+: cy[15]) 
q[1] = (q[1] :+: (ip_add * dl[1]) :+: 
((ip_add * 
(qa[0] * dl[0] + 
dl[0] * cy[15])) + 
(a[0] * cy[15]))) 
q[2] := (q[2] :+: (ip ada * dl1l[2]) ++: 
((ip_add * 
(q[1] * dl[1] + 
qit * q[0] * dl1[0] + 
alii; ALOT- ALLIT -+ 
qii] * dl[0] * cy[15] + 
aby *-dis£0]. * sey: ELS) E 
dal[1] * q[0] * cy[15])) + 
(q[1] * q[0] * cy[15]))) 
cy [2] := ((ip_add * 
(q[2] * dl[2] + 
ql * q[1] * dl[1] + 
d1[2] * qf[1] * dl[1] + 
gial * q{1] * q[0] * ALTOJ + 
qilar * dli[1] * q[0] * dl[0] + 
di[2] * q[1] * q[0] * dl[0] + 
di[2] * dil[1] * q[0] * adl1[0] + 
gi2] * q[1] * dl[0] * cy[15] + 
qlar * dlif{1] * q[0] * cy[15] + 
qi2] * dl[1] * dl[0O] * cy[15] + 
dl[2] * q[1] * q[0] * cy[15] + 
dal [2] * q[1] * Arro] * cy[15] + 
ALZ] *#ALLIT * qo] * ey [Ls] + 
di[2] = dl[1] * dal[0O] * cy[15])) + 
(q{2] * q[l] * q[0] * cy[15])) 
q[3] = (q[3] :+: (ip_add * d1[3]) :+: cy[2]) 
q[4] = (q[4] :+: (ip_add * dl[4]) :+: 
((ip_add * 
(q[3] * dl[3] + 
d1l[3] * cy[2])) + 
(qa[3] * cy[2]))) 
Touch & Parham Informational 


April 1996 


[Page 13] 


RFC 1936 Implementing the Internet Checksum in Hardware 


1 


; the next 3 bits [5..7] of the low-order word 


q[5] := (q[5] :+: (ip_add * d1[5]) :+: 
((ip_add * 
(q[4] * dl[4] + 
qalar * qf{3] * dl[3] + 
ALIAT F -qbe3} * AEFT + 
qi4] * aLi] * cey[2] + 
dl[4] * d1l[3] * cy[2] + 
dal[4] * q[3] * cy[2])) + 
(q[4] * q[3] * cy[2]))) 
cy[5] s= ((ip_add * ( 
q[5] * dal[5] + 
q[5] * q[4] * dl[4] + 
d1[5] * q[4] * dl[4] + 
q[5] * q[4] * q[3] * dal[3] + 
q[5] ALA * q[3] * dl[3] + 
aris * aq[4] * aq[3] * dl[3] + 
als) db lay A qi3d,-* dl [31+ 
giS * q{4]) * dal[3] * cy[2] + 
q[5] * dl[4] * q[3] * cy[2] + 
g[5] * d1l[4] * dl[3] * cy[2] + 
agl[5] * aq[4] * aq[3] * cy[2] + 
alis] *° GM] * ALi] *-cey[2) + 
AESI * d1l[4] * AS * cy[2] + 
d1l[5] * d1l[4] * dal[3] * cy[2])) 
tals] * q[4] * q[3] * cy[2])) 
q[6] := (q[6] :+: (ip_add * dl[6]) :+: cy[5] 
q[7] <=. (G7 s4+e -Gpuadd’ * ALETI) eti 
((ip_add * 
(q[6] * dl[6] + 
arre] * cy[5])) + 
(q[6] * cy[5]))) 
cy [7] := ((ip_add * 
(ETI * dal[7] + 
q[i7] * q[6] * dl[6] + 
ab TL) E ogo), «db Lel -t 
q[7] * dl[6] * cy[5] + 
Ari] * d1l[6] * cy[5] + 
dal[7] * q[6] * cy[5])) + 
(qi7] * q[6] * cy[5])) 
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; the next 5 bits [8. 


q[8] 


q[9] 


q[10] 


cy [10] 


q[11] 


q[12] 
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.12] of the low-order word 
:= (q[8] :+: (ip_add * d1[8]) :+: cy[7]) 
z= (q[9] :+: (ip_add * d1[9]) :+: 
((ip_add * 
(q[8] * dl[8] + 
di[8] * cy[7])) + 
(q[8] * cy[7]))) 
¿= (q[10] :+: (ip_add * d1[10]) :+: 
((ip_add * 
(qi9] * d1[9] + 
q[9] * q[8] * dal[8] + 
dl[9] * q[8] * dl[8] + 
qis] * d1l[8] * cy[7] + 
d1l[9] * d1l[8] * cy[7] + 
d1l[9] * q[8] * cy[7])) + 
(q[9] * q[8] * cy[7]))) 
:= ((ip_add * 
(q[10] * d1[10] + 
q[10] * q[9] * dl[9] + 
ALLO} * Gg Loy =- ak Lod + 
q[10] * q[9] * q[8] * dl[8] + 
q[10] * d1l[9] * q[8] * dl1[8] + 
d1[10] * q[91l * .q[8] * dlls]. + 
dl[10] * d1[9] * q[8] * dl1[8] + 
q[10] * q[9] * d1l[8] * cy[7] + 
q[10] * d1l[9] * gq[8] * cy[7] + 
q[10] * d1l[9] * dal[8] * cy[7] + 
d1[10] * q[9] * q[8] * cy[7] + 
di[10] * q[9] * dal[8] * cy[7] + 
d1[10] * ALES] * atg] * cyLl?] + 
di[10] * dal[9] * dl[8] * cy[7])) + 
(q({10] * q[9] * q[8] * cy[7])) 
:= (q[11] :+: (ip_add * d1[11]) :+: cy[10]) 
:= (q[12] :+: (ip_add * d1[12]) :+: 
((ip_add * 
(q[11] * dl[11] + 
dl[11] * cy[10])) + 
(q[11] * cy[10]))) 
Informational 
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; the final 3 bits [13..15] of the low-order word 


q[13] := (q[13] :+: (ip_add * d1[13]) :+: 
((ip_add * 
(q[12] * dal[12] + 
q[12] * q[11] * dl[11] + 
ALI 2) * “gpl tl: * aL [Lay + 
q[12] * dl[11] * cy[10] + 
dil[1i2] * dl[11] * cy[10] + 
d1[12] * q[11] * cy[10])) + 
(q{12] * q[{11] * cy[10]))) 
cy[13] := ((ip_add * ( 
q[13] * d1[13] + 
q[13] * q[12] * dl[12] + 
aris] * q[12] * dl[12] + 
q[13] * q[12] * q[11] * dl[11] + 
TETIT * d1l[12] * gqf[11] * dl[11] + 
ablia) * “qil2r Z AFLI 4 dk Lie) + 
abl[i3s] *- alflad >. QELI] * -ALLLLIJ + 
q[13] * q[12] * dl[11] * cy[10] + 
FLST * alls. * gair A eyito E 
qf[13] * d1l[12] * dl[11] * cy[10] + 
d1[13] * q[12] * q[11] * cy[10] + 
artisi * q[12] * dl[11] * cy[10] + 
artll] * dl[12] * GEI * cy[10] + 
d1l[13] * dl[12] * dl[11] * cy[10])) + 
(q[13] * q[12] * q[11] * cy[10])) 
q[14] := (q[14] :+: (ip_add * d1[14]) :+: cy[13]) 
q[15] := (q[15] :+: (ip_add * d1[15]) :+: 
((ip_add * 
(q[14] * d1l[14] + 
dl[14] * cy[13])) + 
(q[14] * cy[13]))) 
cy [15] := ((ip_add * 
ALLISTE ALLIS] = 
q[15] * aq[14] * d1l[14] + 
aris] * q[14] * d1[14] + 
Git si sala ey EES + 
d1l[15] * dl[14] * cy[13] + 
aglf[15] = q[14] * cy[13])) + 
alla] * q[{14] * cy[13])) 
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; SUM THE HIGH-ORDER WORD 


1 


; the first 5 bits [16..20] of the high-order word 


q[16] = (q[16] :+: (ip_add * d1[16]) :+: cy[31]) 
q[17] := (q[17] :+: (ip ladd * d1[17]) :+: 
((ip_add * 
(q[16] * dl[16] + 
dl[16] * cy[31])) + 
(q[16] * cy[31]))) 
q[18] := (q[18] :+: (ip _add * d1[18]) :+: 
((ip_add * 
(q{17] * dl[17] + 
q[17] * q[16] * dl[16] + 
dl[17] * q[16] * d1[16] + 
q[17] * dl[16] * cy[31] + 
dl[17] * dl[16] * cy[31] + 
dl[17] * q[16] * cy[31])) + 
(q{17] * q[16] * cy[31]))) 
cy [18] := ((ip_add * 
(q[18] * dl[18] + 
q[18] * [17] * dl[17] + 
dl[18] * q[17] * dl[17] + 
q[18] * [17] * q[16] * d1[16] + 
q[18] * dl[17] * q[16] * d1[16] + 
dl[18] * q[17] * q[16] * dl[16] + 
dl[18] * d1[17] * q[16] * dl[16] + 
q[18] * [17] * dl1[16] * cy[31] + 
q[18] * dl[17] * q[16] * cy[31] + 
q[18] * dl[17] * d1[16] * cy[31] + 
dl[18] * q[17] * q[16] * cy[31] + 
dl[18] * q[17] * d1[16] * cy[31] + 
dl[18] * d1[17] * q[16] * cy[31] + 
dl[18] * d1[17] * d1[16] * cy[31])) + 
(a[18] * q[17] * q[16] * cy[31])) 
q[19] := (q[19] :+: (ip ladd * d1[19]) :+: cy[18]) 
q[20] := (q[20] :+: (ip _add * d1[20]) :+: 


((ip_add * 
(q[19] * d1l[19] + 
dl[19] * cy[18])) + 
(q[19] * cy[18]))) 
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; the next 3 bits [21..23] of the high-order word 
q[21] := (q[21] :+: (ip_add * d1[21]) :+: 
((ip_add * 
(q[20] * d1[20] + 
q[20] * q[19] * d1[19] + 
dgl[20] * q[19] * dl1[19] + 
q[20] * d1[19] * cy[18] + 
d1l[20] * d1[19] * cy[18] + 
al [20] * q[19] * cy[18])) + 
(q[20] * q[19] * cy[18])) 
cy [21] := ((ip_add * ( 
qg[21] * d1[21] + 
q[21] * q[20] * d1l[20] + 
dl[21] * q[20] * dl[20] + 
q[21] * q[20] * q[19] * dl[19] + 
q[21] * dl[20] * q[19] * d1[19] + 
dl[21] * q[20] * q[19] * d1[19] + 
dl1[21] * d1[20] * q[19] * d1[19] + 
qg[21] * q[20] * d1[19] * cy[18] + 
q[21] * dl[20] * q[19] * cy[18] + 
q[21] * d1[20] * d1[19] * cy[18] + 
dl[21] * gq[20] * q[19] * cy[18] + 
GL ZL] =- se [204 AALLS] * Vey PVs]. + 
dl1[21] * d1[20] * q[19] * cy[18] + 
d1[21] * d1[20] * d1[19] * cy[18])) 
(q([21] * q[20] * q[19] * cy[18])) 
q[22] := (q[22] :+: (ip_add * d1[22]) :+: cy[21]) 
q[23] := (q[23] :+: (ip_add * d1[23]) :+: 
((ip_add * 
(q[22] * d1[22] + 
dl[22] * cy[21])) + 
(q[22] * cy[21]))) 
cy [23] := ((ip_add * 
(q[23] * d1[23] + 
qg[23] * q[22] * d1l[22] + 
d1[23] * q[22] * d1l[22] + 
q[23] * d1[22] * cy[21] + 
d1[23] * d1[22] * cy[21] + 
d1[23] * q[22] * cy[21])) + 
(q[23] * q[22] * cy[21])) 
Touch & Parham Informational 
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; the next 5 bits [24. 


q[24] 


q[25] 


q[26] 


cy[26] 


q[27] 


q[28] 


Implementing the Internet Checksum in Hardware 


z= (q[24] sfe 


:= (q[25] :+: 


((ip_add * 
(q[24] 
dl [24] 


s= (q[26] :+: 


((ip_add * 
(q[25] 
q[25] 
d1[25] 
q[25] 
d1[25] 
d1[25] 

(q[25] * g[24] 


:= ((ip_add * 


(q[26] 
q[26] 
dl[26] 
q[26] 
q[26] 
dl[26] 
dl[26] 
q[26] 
q[26] 
q[26] 
dl[26] 
dl[26] 
dl[26] 
dl[26] 
(q[26] * g[25] 


= (q[27] ets 


:= (q[28] :+: 


((ip_add * 
(q[27] 
dl [27] 


Touch & Parham 


.28] 
(ip_add * d1[24]) :+: 


(ip_add * dl[25]) :+: 


* dl[24] + 
SacyiZ3])) yt 
(q[24] * cy[23]))) 


(ip_add * dl[26]) :+: 


* d1[25) + 

* q[24] * d1l[24] + 
* q[24] * d1l[24] + 
* dl[24] * cy[23] + 
* d1[24] * cy[23] + 
* q[24] * cy[23])) 
* cy[23]))) 

* d1[26] + 

* q[25] * d1l[25] + 
* q[25] * d1l[25] + 
* q[25] * q{[24] * 
* d1[25] * q[24] * 
* q[25] * q[24] * 
AA EZS A €24]. * 
* AF25]: * AL [a4]. * 
* d1[25] * q{[24] * 
* d1[25] * d1l[24] * 
* q[25] * q[24] * 
* oO EZoil  * Od [2A] X 
*-al[25] * q[24] * 
* dal [25] * dl[24] * 
* 


(ip_add * d1[27]) +s 


(ip_add * dl[28]) :+: 


q[24] * cy[23])) 


* dl[27] + 
* cy[26])) + 
(q[27] * cy[26]))) 


Informational 


of the high-order word 


cy[23]) 


dl[24] + 
dl[24] + 
dl[24] + 
dl[24] + 
cy[23] + 
cy[23] + 
cy[23] + 
cy[23] + 
cy[23] + 
cy[23] + 
cy[23])) 


cy[26]) 
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a 


; the final 3 bits [29..31] of the high-order word 


q[29] := (q[29] :+: (ip_add * d1[29]) :+: 
((ip_add * 
(q[28] * d1[28] + 
q[28] * q[27] * dl[27] + 
dl[28] * q[27] * dl[27] + 
q[28] * d1[27] * cy[26] + 
d1[28] * dl[27] * cy[26] + 
d1[28] * q[27] * cy[26])) + 
(q[28] * q[27] * cy[26]))) 
cy [29] := ((ip_add * ( 
q[29] * d1[29] + 
q[29] * q[28] * d1l[28] + 
dl[29] * q[28] * d1[28] + 
q[29] * q[28] * q[27] * dl[27] + 
q[29] * d1[28] * q[27] * dal[27] + 
dl[29] * q[28] * q[27] * dal[27] + 
d1[29] * dl[28] * q[27] * dal[27] + 
q[29] * q[28] * dl1[27] * cy[26] + 
q[29] * d1[28] * q[27] * cy[26] + 
q[29] * dl[28] * d1[27] * cy[26] + 
aL[29] * @[28] * -ql27] *'éy[26] + 
dl[29] * q[28] * d1[27] * cy[26] + 
d1[29] * dl[28] * q[27] * cy[26] + 
dl[29] * d1[28] * d1[27] * cy[26])) + 
(q[29] * q[28] * q[27] * cy[26])) 
q[30] := (q[30] :+: (ip_add * d1[30]) :+: cy[29]) 
q[31] := (q[31] :+: (ip_add * d1[31]) :+: 
((ip_add * 
(q[30] * d1[30] + 
dl[30] * cy[29])) + 
(a[30] * cy[29]))) 
cy [31] := ((ip_add * 
(q[31] * d1[31] + 
q[31] * q[30] * dl[30] + 
dl[31] * q[30] * d1[30] + 
q[31] * dl[30] * cy[29] + 
dl[31] * dl[30] * cy[29] + 
d1[31] * q[30] * cy[29])) + 
(q[31] * q[30] * cy[29])) 
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i 
; output nodes onto output pins (pending enable..) 


d 


dq[0] >= {q[0]} 
dq[1] >= {q[1]} 
dq[2] >= {q[2]} 
dq[3] >= {q[3]} 
dq[4] >= {q[4]} 
dq[5] = {q[5]} 
dq[6] = {q[6]} 
dq[7] >= {q[7]} 
dq[8] >= {q[8]} 
dq[9] := {q[9]} 
dq[10] := {q[10]} 
dq[11] := {q[11]} 
dq[12] = {q[12]} 
dq[13] = {q[13]} 
dq[14] := {q[14]} 
daq[15] := {q[15]} 
dq[16] := {q[16]} 
dq[17] := {q[17]} 
dq[18] = {q[18]} 
dq[19] := {q[19]} 
dq[20] := {q[20]} 
dq[21] := {q[21]} 
dq[22] := {q[22]} 
dq[23] = {q[23]} 
dq[24] = {q[24]} 
dq[25] := {q[25]} 
daq[26] := {q[26]} 
dq[27] := {q[27]} 
dq[28] := {q[28]} 
dq[29] = {q[29]} 
dq[30] = {q[30]} 
dq[31] := {q[31]} 
; end. 
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